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Abstract 

Multicast  networking  support  is  becoming  cm 
increasingly  important  technology  area  for  both 
commercial  and  military  distributed  or  group-based 
applications.  The  underlying  delivery  mechanism  for 
IP  multicast  is  presently  the  User  Datagram  Protocol 
(UDP)  or  raw  IP  packets.  At  present,  these 
mechanisms  provide  a  "best  effort"  delivery  service. 
Best  effort  implies  that  IP  packets  are  treated  with 
essentially  equal  weight,  and  while  IP  makes  car 
effort  to  deliver  cdl  packets  to  their  destination, 
packets  may  be  occasionally  be  delayed,  lost, 
duplicated,  or  delivered  out  of  order.  In  the  past 
such  delivery  mechanisms  have  worked  fine  for 
supporting  traffic  insensitive  to  occasional  lost  or 
missing  data  (e.g..  voice,  video).  An  increasing 
variety  of  distributed  multimedia  applications  are 
being  developed  in  which  a  consistent  and/or  reliable 
data  delivery  of  all  or  a  subset  of  data  packets  is  a 
critical  performance  factor.  In  future  military  tactical 
internetworks,  situational  awareness  data  will  play  a 
major  role  as  a  critical  multicast  application.  Reliable 
group  file  transfer  (e.g..  image  dissemination)  and 
interactive  mission  planning  applications  are  also 
likely  applications  for  military  mobile  units. 

This  paper  presents  a  taxonomy  of  presently 
available  reliable  multicasting  solutions.  The 
protocols  are  classified  in  terms  of  performance 
issues  and  scalability.  Using  this  taxonomy,  reliable 
multicast  solutions  are  considered  for  various 
military  applications  such  as  mission  planning, 
Distributed  Interactive  Simulation  (DIS),  and 
situational  awareness  dissemination  in  a  shared 
WAN  environment. 

Introduction 

The  current  model  for  IP  multicast  delivery  is 
increasingly  inadequate  for  the  variety  of  multicast 
applications  being  developed.  In  particular, 
providing  a  degree  of  reliability  is  critical  for  many 
applications.  Currently,  several  reliable  multicast 
solutions  are  available  and  many  approaches  are 


being  developed.  To  aid  in  understanding  the 
reliable  multicast  solutions  that  are  available,  a 
general  classification,  or  taxonomy,  of  reliable 
multicast  techniques  is  presented  in  the  following 
section.  This  taxonomy  is  then  applied  to  several 
example  military  applications  to  give  the  reader  some 
idea  of  the  issues  that  must  be  considered  when 
selecting  or  designing  a  reliable  multicast  approach 
for  a  particular  application  class  and  scalability  goal. 

Application  Requirements 

Multicast  applications  require  varying  degrees 
of  reliability  and  ordering.  Understanding  these 
requirements  aids  in  classifying  reliable  multicast 
design. 

Reliability  Requirements 

Application  reliability  requirements  can  be 
loosely  defined  as  follows  [51]. 

•  Best  effort  reliability  is  similar  to  that  which  is 
provided  by  the  UDP-based  IP  multicast 
delivery  schemes  most  commonly  present 
today.  No  reliable  delivery  is  guaranteed. 

•  Absolute  reliability  is  the  most  familiar 
requirement.  It  states  that  all  packets  in  a 
session  be  reliably  delivered  to  the  receivers. 
This  is  the  form  of  reliability  that  is  commonly 
supported  by  TCP  at  the  transport  layer  for 
unicast  sessions. 

•  Bounded  latency  requires  that  each  packet 
adheres  to  a  specified  lifetime  over  which  the 
data  is  useful  to  the  receiver.  This  is  defined  as 
an  upper  bound  on  its  delivery  latency. 
Packets  arriving  outside  this  timeframe  are 
discarded.  The  common  application  requiring 
bounded  latency  is  a  video  stream.  Each  packet 
has  a  "playback"  time  and  any  packet  not 
meeting  this  deadline  is  discarded. 

•  Most  recent  reliability  is  reliable  transmission 
where  only  the  most  recent  data  of  a  particular 
parameter  is  of  interest.  A  simple  example 
would  be  a  service  that  provides  reliable  stock 
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updates.  If  a  particular  stock  update  is  lost,  error  detection.  This  is  a  basic  selective  repeat 

and  a  new  update  is  received  before  a  approach.  However,  IP  multicast  implies  no  direct 

retransmission  can  occur,  the  old  data  is  relationship  between  senders  and  receivers  of 

rendered  useless.  Thus,  it  is  possible  that  the  multicast  data.  This  severely  hampers  the  ability  of  a 

data  may  take  on  a  value  that  is  never  known  to  sender  to  track  and  maintain  reception  state  for  each 

some  or  all  of  the  receivers.  Most  recent  receiver.  Even  if  each  sender  is  made  aware  of  all 

reliability  is  a  common  requirement  for  many  receivers,  a  severe  ACK  implosion  effect  is  created  at 

data  types  in  advanced  distributed  simulations  each  sender  when  the  number  of  receivers  grows 

and  in  situational  awareness  dissemination.  large  (e.g.,  >  10  participants)  [30]. 


Ordering 

Multicast  applications  may  also  be  classified 
by  their  ordering  requirements.  These  may  be 
broadly  classified  into  the  following  categories  [51]: 

•  Ordered  delivery  means  that  packets  are 
delivered  to  the  receiver's  application  layer  in 
the  sequence  that  they  were  transmitted.  This 
is  the  ordering  classification  delivered  by  TCP 
for  unicast  transmission  [14]. 

•  Unordered  delivery  allows  the  reliability 
mechanism  to  deliver  the  packets  in  any  order. 

•  Causally  ordered  delivery  further  requires  the 
reliability  mechanism  to  maintain  ordering 
across  distributed  processes  [17].  For  example 
if  application  A  transmits  m,  to  applications  B 
and  C,  then  B  on  receiving  nq  transmits  m2  to 
C,  the  reliability  mechanism  requires  that  m,  is 
received  at  C  before  m2. 

•  Totally  ordered  delivery  specifies  that  multiple 
multicast  streams  from  multiple  senders  are 
delivered  sequentially  to  each  receiver  and  are 
received  in  the  same  relative  order  at  each 
receiver. 

•  Causal,  totally  ordered  delivery  specifies  totally 
ordered  delivery  that  does  not  violate  causality. 

Reliable  Multicast  Taxonomy 

Reliable  multicast  protocols  can  be  grouped 
into  two  broad  classes,  sender-reliable  and  receiver- 
reliable  multicast.  Each  classification  is  based  on  the 
sender's  knowledge  of  the  multicast  group  and 
which  party  has  the  responsibility  for  state 
maintenance  and  the  initiation  of  error  correction 
[30], 

Sender-reliable 

In  this  approach,  reliable  delivery  is  primarily 
the  responsibility  of  the  sender.  The  sender  monitors 
the  reception  state  of  each  receiver  through  positive 
acknowledgment  (ACK)  and  issues  repairs  upon 


This  approach  is  appropriate  when  absolute 
control  must  reside  at  the  sender  (e.g.,  security 
reasons),  but  for  most  applications  the  approach  does 
not  scale  due  to  the  ACK  implosion  effect  and  the 
requirement  of  the  sender  to  track  state  of  all 
receivers. 

Receiver-reliable 

For  receiver  reliable  multicast,  reliable 
delivery  is  the  responsibility  of  the  receivers.  Each 
receiver  maintains  reception  state  and  requests  repairs 
via  a  negative  acknowledgment  (NACK)  when  an 
error  is  detected. 

Error  detection  is  based  on  the  receiver 
perceiving  gaps  in  the  data.  This  requires  that 
individual  packets  be  identified  either  with 
application  level  framing  or  generic  transport 
sequence  numbers  as  in  TCP.  Low  latency  gap 
detection  requires  frequent  data  transmission, 
otherwise  "heartbeat"  or  "keep  alive"  transmissions 
are  necessary. 

In  receiver  reliable  systems,  mixed  levels  of 
reliability  can  be  achieved  at  a  receiver.  A  receiver 
may  choose  to  NACK  any  missing  data  it  requires  to 
be  reliable.  The  data  packet  may  be  encoded  to 
indicate  a  reliability  requirement.  Encoding  reliability 
at  the  application  layer  affords  the  most  flexibility  as 
many  levels  of  reliability  are  possible. 

There  are  several  classes  of  receiver-reliable 
approaches  that  are  discussed  below: 

Sender-oriented 

In  sender-oriented  approaches  an  error 
detection  at  a  receiver  results  in  a  NACK  sent  to  the 
sender.  While  intermediate  receivers  may  have 
received  the  data  for  which  the  NACK  is  issued, 
only  the  sender  is  involved  in  issuing  repairs.  This 
approach  is  appropriate  when  receivers  cannot 
communicate  with  each  other  (perhaps  for  security 
reasons).  However,  such  an  approach  ultimately 
limits  scalability  due  to  a  NACK  implosion  effect  at 
the  sender  for  large  receiver  sets  Thus,  such  an 
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approach  is  best  suited  for  transmission  of  very  large 
packets  where  a  low  ratio  of  NACK  overhead  to  data 
content  can  be  realized.  This  reduces  the  overall 
NACK  implosion  effect. 
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detecting  an  error  issues  a  NACK.  To  make  this 
scheme  work  well  a  distributed  repair  scheme  is 
required  which  suppresses  the  number  of  control 
messages  required  per  repair. 


To  explore  the  effects  of  unsuppressed 
NACK  implosion,  we  simulated  a  set  of  symmetric 
multicast  trees  with  an  independent  probability  of 
packet  loss  p  due  to  congestion  at  tree  nodes.  Each 
multicast  tree  of  depth  cl  and  fan-out  n  contains 
members  at  branch  and  leaf  nodes.  Upon  a  packet 
loss  at  a  node,  all  children  of  this  parent  are  declared 
to  all  produce  a  NACK  message  The  total  number  of 
NACK  messages  is  obtained  and  averaged  over  a 
large  set  of  trials.  This  produces  an  expected  value 
of  NACKs  for  a  given  tree  and  failure  probability 

[51]. 

Figure  1.  shows  the  average  results  of 
100,000  trials  for  nodes  with  a  fan-out,  n=4,  and 
tree  depths,  d  =  4,5,6.  The  NACK  implosion  effect 
is  quite  apparent  as  the  size  of  the  tree  and  the  packet 
loss  per  node  increases.  Even  in  cases  where  raw 
link  error  rates  are  very  low,  the  probability  of  packet 
loss  can  be  quite  high,  due  to  router  congestion  and 
other  effects. 


-d=4,n=4 

-d=5,n=4 

-d=6,n=4 


Probability  of  Packet  Loss 

Figure  1:  NACK  implosion  simulation 


Flat  Receiver-Oriented 

In  a  flat  receiver-oriented  approach  to  reliable 
multicast,  receivers  can  communicate  with  each  other 
to  assist  in  error  recovery.  Each  receiver  caches  data 
for  some  time  or  for  the  entire  session.  When  an 
error  is  detected  at  a  receiver,  a  NACK  is  issued 
which  other  receivers  can  hear  since  it  is  multicast  to 
the  group.  When  a  receiver  that  has  correctly 
received  and  cached  the  missing  data  receives  the 
NACK  a  repair  can  be  issued.  This  in  itself  would 
not  reduce  the  NACK  implosion  effect  since  the 
NACK  is  sent  to  the  whole  group  and  any  receiver 


When  a  receiver  detects  an  error,  it  is  likely 
that  other  downstream  and  equidistant  receivers  will 
also  experience  the  error.  In  addition,  equidistant  (in 
terms  of  delay)  receivers  will  detect  the  error  at 
roughly  the  same  time.  To  reduce  the  chance  of  all 
such  receivers  issuing  redundant  NACKs  at  once, 
each  receiver  sets  a  random  timer  upon  error 
detection.  When  the  timer  expires,  if  a  NACK  for 
the  missing  data  has  not  already  been  heard,  the 
receiver  issues  a  NACK.  When  a  receiver  that  has 
correctly  received  and  cached  the  missing  data  hears 
a  NACK,  another  random  timer  is  set.  When  this 
timer  expires,  if  a  repair  has  not  been  heard,  one  is 
issued.  This  reduces  the  number  of  redundant 
repairs  that  might  be  sent  by  equidistant  receivers 
simultaneously  receiving  NACKs  [9,10,38,49]. 

Deterministic  suppression  is  also  possible 
along  a  linear  topology  [38,51].  This  is  useful  when 
downstream  receivers  also  detect  the  same  errors  as 
upstream  receivers.  By  accurately  estimating  the 
delay  between  receivers,  the  uniform  distribution  of 
the  downstream  random  timers  can  be  adjusted  to 
produce  longer  delays.  Thus,  it  is  likely  that  a 
downstream  receiver  will  observe  the  NACK  of  an 
upstream  receiver  before  issuing  his  own  NACK. 

Since  most  networks  exhibit  both  linear  and 
star  (equidistant)  characteristics,  a  combination  of 
randomized  and  deterministic  NACK/repair 
suppression  should  be  used  for  a  flat,  receiver- 
oriented  reliability  scheme  [38]. 

A  drawback  to  a  flat  receiver-oriented 
approach  is  that  NACKs  and  repairs  are  global  in 
scope.  Thus,  they  consume  bandwidth  for  the  whole 
group  even  for  isolated  packet  losses.  Enhanced 
localized  scoping  of  repair  messages  is  possible  and 
can  alleviate  this  effect  [38,50,51].  In  general  a  flat, 
receiver-based  approach  is  highly  fault  tolerant  and 
scaleable.  Its  biggest  disadvantage  is  in  the 
requirement  to  cache  state  at  all  receivers.  This  is  not 
really  a  weakness  for  some  applications,  such  as  an 
interactive  whiteboard  [9,10],  in  which  state  may  be 
maintained  regardless.  However,  for  long-lived 
applications  requiring  significant  buffering  this  could 
quickly  become  a  nuisance. 

Hierarchical,  receiver-oriented 

To  improve  scalability  performance  and  allow 
for  distributed  state  garbage  collection  and  more 
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organized  repairing  schemes,  it  is  possible  to 
introduce  a  hierarchy  into  a  reliable  multicasting. 
Several  hierarchical,  reliable  multicasting  approaches 
have  been  proposed.  One  such  approach  [36]  forms 
a  hierarchy  of  caching  loggers,  to  which  a  receiver 
NACKs  for  a  repair.  Another  [51]  forms  a  self 
organizing  shared  repair  tree.  Localized  scoping  in 
this  approach  limits  repair  dissemination  and  the 
hierarchy  aids  in  buffer  management.  A  similar 
approach  is  the  Tree-based  Multicast  Transport 
Protocol,  TMTP  [50]  which  forms  source  based 
trees  for  a  repair  hierarchy.  The  scoped  repairs  are 
used  for  state  management  and  error  recovery. 
There  are  limited  performance  results  to  understand 
the  various  performance  tradeoffs  of  each  approach. 
In  summary  further  study  of  this  topic  is  warranted. 
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This  is  not  an  issue  for  any  application 
requiring  bounded  latency  reliability  since  the  sender 
is  free  to  discard  data  that  cannot  meet  the  reception 
deadline.  However,  the  validity  of  absolutely 
reliable  data  never  expires  and  must  be  delivered. 
Thus,  the  sender  cannot  arbitrarily  discard  the  data. 

Supporting  absolute  reliability  requires  some 
form  of  ACKing  mechanism  from  the  receivers 
which  allows  the  sender  to  periodically  flush  its 
buffers.  This  ACKing  mechanism  can  be  used  in 
conjunction  with  a  more  general  NACK  error 
recovery  approach  and  should  be  as  infrequent  as 
possible  to  reduce  ACK  implosion  and  general 
overhead.  This  mechanism  also  requires  the  senders 
to  have  knowledge  of  the  set  of  receivers  at  any 
given  time. 


Reliability 

Mode 

Error 

Detection 

Repair  State 

Scalability 

Sender 

Sender 

Sender 

Low:  due  to  ACK  implosion 

Receiver 

Receiver 

see  Table  2 

see  Table  2 

Table  1:  Reliable  Multicast  Approaches 


Repair  Orientation 

NACK  Scheme 

Repair  Scheme 

Scalability 

Sender-Oriented 

Receivers  NACK 
to  Sender 

Sender  issues  repair  to 
group 

Moderate:  Least  scalable  of  receiver- 
reliable  approaches. 

Flat,  Receiver- 
oriented 

Receivers  NACK 
errors  to  group 

Receivers  cache  data  and 
can  issue  repairs 

High:  Limits  Nack  implosion  effect, 
but  distributed  buffering  required. 

Hierarchical 

Receivers  NACK 
to  some 

hierarchical  node 
or  group 

Hierarchical  nodes 
successively  responsible 
for  buffering  and  issuing 
repairs 

Very  high:  Excellent  scalability  and 
limited  network  overhead.  Allows 
for  more  controlled  buffer 
management. 

Table  2:  Receiver  Reliable  Approaches 


Supporting  Absolute  Receiver-Reliable 
Service 

Support  of  absolute  reliability  in  a  receiver- 
reliable  approach  imposes  constraints  on  senders. 
Since  senders  are  not  tracking  receiver  reception 
state,  at  any  point  in  the  future  a  receiver  may  require 
a  retransmission.  Strictly  speaking  this  requires  the 
sender  to  buffer  data  indefinitely.  This  represents  a 
problem  if  the  sender  is  participating  in  a  long-lived 
session  given  finite  storage  capacity. 


Thus,  any  scheme  supporting  absolute 
reliability  represents  a  mixed  requirement  of  both 
sender-reliable  and  receiver-reliable  multicast. 

Summary 

Tables  1  and  2  summarize  the  taxonomy  of  reliable 
multicast  protocols  presented  in  this  section. 

Military  Applications 

In  this  section,  we  consider  some  military 
applications  that  will  require  or  might  benefit  from 
reliable  multicasting  capabilities.  In  each  case,  we 
examine  some  of  the  requirements  the  application 
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demands  from  a  reliable  multicast  protocol,  and 
discuss  which  protocol  class  (as  per  the  taxonomy)  is 
a  "best  fit"  for  that  application.  The  goal  is  not  to 
mandate  an  approach  for  each  of  the  applications,  but 
rather  highlight  some  of  the  issues  that  must  be 
considered  when  selecting  or  designed  a  reliable 
multicast  approach  for  a  particular  application. 

Situational  Awareness  Applications 

Situational  awareness  applications  will  likely 
require  reliable  dissemination  of  information  to 
multiple  parties.  To  the  extent  that  this  dissemination 
is  desired  will  compound  the  impact  scalability  issues 
will  have.  If  the  situational  awareness  data  is  sent  to 
the  brigade  or  battalion  level,  scalability  is  not  as 
important  as  if  the  data  is  transmitted  to  the  individual 
soldier.  Since  survivability  will  be  affected,  the  data 
must  be  reliably  sent.  Low  to  moderate  available 
bandwidth  will  mandate  that  multicast  be  used. 
However,  there  are  aspects  of  this  data  lead  to  a 
mixture  of  reliability  requirements.  Clearly,  there 
will  be  situational  data  that  is  "most  recent"  reliable. 
This  may  be  data  with  an  object-oriented 
characteristic  such  as  tracking  information  of  an 
oncoming  enemy.  If  a  previous  position  report  is 
lost,  but  a  newer  report  is  received,  the  old  report  is 
often  rendered  useless.  In  addition  to  the  object- 
oriented  form  of  reliability,  a  component  of  data 
exists  that  must  be  absolutely  delivered  reliably. 
This  is  message-oriented  information  such  as  a  "one¬ 
time"  report  of  a  hazard  (say  a  minefield)  which 
should  absolutely  get  to  all  interested  parties. 

Since  the  number  of  receivers  is  likely  to  be 
large  (if  taken  to  the  individual  level),  receiver 
reliable  schemes  seem  most  appropriate  to  improve 
scalable  performance  and  with  appropriate  NACK 
suppression  will  reduce  the  likelihood  of  control 
message  implosion  effects.  Since  the  forming  of 
hierarchies  will  be  difficult,  as  most  of  the  parties 
will  be  highly  mobile,  a  flat  receiver  reliable 
approach  is  simplest  and  most  robust.  To  generate 
the  granularity  of  reliability  required  (most  recent  vs. 
absolute)  different  multicast  groups  can  be  used,  the 
multicast  group  that  has  an  absolute  requirement  can 
be  perceived  as  a  priority  channel. 

Imagery  Dissemination: 

Imagery  dissemination  applications  can  be 
characterized  by  large  infrequent  packet 
transmissions  (with  some  exceptions).  For  the  most 
part,  the  data  should  be  considered  absolutely 
reliable.  If  the  number  of  recipients  is  small,  a 
sender  reliable  approach  is  acceptable.  If  there  are 


too  many  receivers  such  that  ACK  implosion  is  a 
severe  problem,  then  a  receiver-reliable  approach 
should  be  adopted.  Since  there  will  likely  be  only 
one  sender  of  images,  a  sender  oriented,  receiver 
reliable  approach  might  be  considered,  but  only  if  a 
handy  mechanism  for  group  awareness  at  the  sender 
is  possible.  This  requires  only  the  sender  to  buffer 
potentially  large  amounts  of  data.  Since  there  is  no 
latency  bound  on  the  data  being  transmitted,  the 
sender  might  have  to  buffer  data  indefinitely.  Thus, 
a  mixed  sender/receiver  reliable  scheme  might  be 
considered  to  alleviate  this  problem.  Again  the 
periodic  ACKs  from  receivers  require  the  sender  to 
track  a  certain  amount  of  receiver  state,  and  thus  be 
group  aware.  Clearly,  this  application  is  afforded 
great  flexibility  when  considering  a  reliable  multicast 
approach,  as  many  different  approaches  will  work 
per  given  scenario. 

Command  and  Control: 

Many  command  and  control  applications  are 
distributed  over  several  mobile  platforms.  The  users 
of  these  distributed  applications  require  a  consistent 
environment  in  which  to  make  correct  decisions. 
Since  these  applications  share  information  among 
many  participants,  they  can  benefit  from  multicast 
communication.  The  requirement  to  maintain  a 
consistent  environment  leads  the  application  to 
reliable  multicast. 

As  in  situational  awareness  applications  some 
of  the  data  that  is  transmitted  is  "most  recent"  reliable 
whereas  some  is  absolutely  reliable.  If  a  track  update 
is  lost,  but  a  new  track  update  is  received  before  the 
old  is  retransmitted,  the  old  update  is  rendered 
useless.  However,  a  one-time  event  such  as  a 
submarine  contact  might  require  absolute  reliable 
transmission  to  all  participants. 

Given  the  large  number  of  participants 
sharing  the  data,  sender  reliable  schemes  will  likely 
not  scale.  Many  command  and  control  applications 
are  considering  the  use  of  voice  and  video  services  to 
augment  the  traditional  C2  functions  (becoming  C3 
and  C4I  systems).  Since  this  data  has  bounded 
latency  constraints,  indefinite  buffering  at  the  senders 
is  not  required.  The  "one-time"  reports  that  require 
absolute  reliability  may  be  infrequent  enough  or 
small  enough  such  that  no  positive  ACKs  from 
receivers  are  necessary  to  clear  buffers.  As  a  result, 
ACK  implosion  can  be  altogether  avoided  by  not 
adopting  any  sender-reliable  approach. 
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Distributed  Interactive  Simulation 

Distributed  interactive  simulation  can  (and 
does)  benefit  from  a  reliable  multicast  solution.  The 
majority  of  DIS  traffic  is  characterized  by  frequent 
position  updates  to  some  or  all  of  the  participants  in 
the  simulation.  Other  events  such  a  terrain  or 
environmental  events  may  be  "one-time"  occurrences 
that  are  never  again  transmitted.  Lastly,  there  are 
some  simulations  that  are  incorporating  command 
and  control  data  over  the  same  networks  to  enhance 
the  realism  of  the  simulation.  This  type  of  data  is 
“message-oriented”  and  may  be  characterized  as 
multicast  file  transfers  over  the  simulation  network. 
However,  we  again  have  a  situation  where  multiple 
levels  of  reliability  must  be  delivered.  The  "most 
recent"  reliable  data  corresponds  to  entity  state 
packets  (which  are  changing  frequently)  and  the 
absolutely  reliable  data  may  include  things  as  Fire 
messages,  detonation  messages,  terrain  updates,  and 
environmental  updates.  A  consistency  protocol  is 
used  in  these  cases  to  maintain  a  reliable,  coherent 
simulation  [49].  Message-oriented  reliability  features 
are  being  considered  as  extensions  to  the  consistency 
protocol  approach. 

Given  the  severe  scalability  issues  inherent  in 
DIS  applications,  only  receiver  reliable  schemes 
should  be  considered.  Even  then,  NACK  implosion 
will  be  a  serious  problem  when  multicast  group 
membership  grows  large.  The  problem  is 
compounded  by  the  fact  that  most  receivers  are  also 
senders  of  data. 

Multicast  Key  Management 

This  may  be  an  application  where  sender- 
reliable  is  the  best  fit.  The  inherent  nature  of  the 
problem  requires  that  the  sender  know  of  all 
receivers  up  front,  although  one  can  envision  a 
hierarchical  approach  for  distribution  management  to 
improve  scalability.  If  infrequent  transmission  is  a 
characteristic  of  the  approach,  then  allowing  explicit 
positive  acknowledgment  from  each  receiver  can 
enhance  robustness  and  the  security  properties  of  the 
scheme.  The  requirements  for  multicast  key 
management  are  not  entirely  clear  at  present  and  this 
in  excellent  area  for  future  study. 

Mission  Planning  Systems 

Mission  planning  systems  can  benefit  from 
reliable  multicast  through  the  dissemination  of  Air 
Tasking  Orders  (ATOs)  via  reliable  multicast.  Such 
traffic  can  be  characterized  as  large  infrequent 


packets.  This  traffic  is  similar  to  that  of  imagery 
dissemination  discussed  above.  This  application  is 
afforded  the  same  flexibility  when  selecting  a  reliable 
multicast  approach  for  this  data. 

If  the  mission  planning  systems  are  further 
augmented  with  some  form  of  "whiteboard" 
application  the  requirements  change  significantly. 
Whiteboard  applications  can  benefit  from  infinite 
buffering  during  the  session.  When  a  new  member 
joins  the  whiteboard  session,  any  of  the  receivers 
within  the  session  can  send  the  current  whiteboard 
pages  since  all  data  has  been  buffered.  The  data  is 
stored  until  it  is  erased  by  a  participant. 

Conclusions 

This  paper  serves  as  a  general  guideline  for 
classifying  reliable  multicast  protocols.  To  be  sure, 
some  protocols  can  be  envisioned  that  exist  beyond 
the  scope  of  the  general  taxonomy  put  forth,  but  the 
major  issues  such  as  scalability  will  still  apply.  The 
military  examples  presented  in  the  previous  section 
should  aid  in  applying  reliable  multicast  approaches 
to  other  applications. 
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